Release notes for wwwopac.ashx 3.7.14013
Preferred terms in autocomplete result
From wwwopac.ashx version 3.7.14013, preferred terms are automatically included in the search result of the autocomplete command. If a retrieved term or name is a non-preferred term, its preferred term or name will be retrieved as well: in the search result XML, the <term> and the <preferred_term> node are contained in a single <record> node.
Conditionally including fields in the API search result
From version 3.7.13340.2, it is possible to conditionally include fields in the wwwopac.ashx search result, by specifying a condition per field in either or both the <brieffields> and <detailfields> sections per <databaseConfiguration> in the adlibweb.xml configuration file. In previous versions, all fields specified in these sections were retrieved, regardless of their contents, which meant that any undesirable content had to be filtered out by an appropriate XSLT stylesheet. The new conditional include allows you to specify that (an occurrence of) a field can only be retrieved if it meets a condition determined by a search language statement of your choice, the advantage being that private or otherwise inappropriate data will never end up in the raw XML of a search result and that it doesn't need to be filtered out afterwards.
<field> node, named includeIf. An example of a single conditionally included field would be the following:<field includeIf="credit.type=Director">credit.name
</field>In between the double quotes you can enter any advanced search language statement acceptable to the wwwopac.ashx
search command*. The meaning of the example is that (the value of) an occurrence of the credit.name field will only be returned in the search result if the same field group occurrence of the credit.type field contains the value 'Director' (assuming both fields are in the same field group): if other field group occurrences contain a credit type other than 'Director', then the value of the corresponding credit name (if present) will not be returned in the search result. Other fields without condition in the <brieffields> and <detailfields> sections (even if they are part of the same field group and appear in a non-'Director' field group occurrence, can always be returned in the search result. So if you want to control all fields of a field group, you'll have to apply a condition to each of them.If the fields in the condition and the field to be included are not part of the same data dictionary field group, or aren't part of any field group, then with the example above, all field occurrences of
credit.type would be checked and if at least one of them would contain the value "Director", then all occurrences of the credit.name field would be retrieved.Note that the search language also allows you to use Boolean AND and OR, so you can make more complex include conditions. If you would like to build a condition to find occurrences which are unequal to a certain value, use
<> where you would normally use =.
* One final important aspect concerns linked fields. In normal search statements you can search linked fields like you would search non-linked fields: on value. To search on a linked field value means that the link has to be "resolved" first, that is: in the main record, only the record number (the link reference) of the linked record has actually been stored, so internally some redirecting and processing has to be done before let's say a catalogue record can be found using a value from an authority database. However little time this takes, everything counts in large amounts. So to have conditional includes based on search statements involving linked fields would quickly lead to a performance drop. Therefore this functionality has been coded in such a way that parsing of the includeIf attribute will not resolve links. As a consequence, you cannot normally search on a linked field value here (so the example above only works if credit.type and credit.name are non-linked fields). However, instead of searching on the linked field value we can search on the link reference value itself, since this value is stored in the main record just like all other non-linked fields, giving you maximum performance. A minor downside perhaps is that you have to look up the record number of any linked value you wish to use in your search statement: in Axiell Collections you can do that in the linked database itself, for instance, by searching for the record of the actual value. So if the credit.type field were actually a linked field, with link reference field credit.type.lref and 74960 the number of the linked record containing the value 'Director', then our example would change into: <field includeIf="credit.type.lref='74960'">credit.name
</field>.New <addToQuery> setting for adlibweb.xml
With the existing <addToQuery> setting in the globalsettings.xml file of an Axiell Internet Server web application, you can specify a part of a search statement that must always be added (implicitly with a Boolean AND) to queries in that database. This way you can shield certain content on field level, to prevent certain records from being retrieved. From wwwopac.ashx 3.7.13332.1, this setting can also be made per <databaseConfiguration> section in adlibweb.xml for wwwopac.ashx. Besides the advantage of having the option available at the WebAPI level so that all software calling the WebAPI can be restricted with this setting, it may allow you to use a q= search for simple searching multiple fields at once instead of a normal search= query, which can boost the performance of searching.
So, per <databaseConfiguration> in adlibweb.xml you can now add the <addToQuery> setting and in it specify a partial search statement: until the wwwopac version from 2013-12-19 (version unknown), here, the partial search statement always had to start with a Boolean operator (AND, AND NOT, OR), for example: <addToQuery>and y1=public</addToQuery>, if y1 were the tag of a field in which you could register whether a record must be publicly available or not. Wwwopac.ashx versions after that date require a partial search statement without Boolean operator: the Boolean AND operator is now always implied. The added partial query can be different for each database and it applies to both search= and q= queries.
With this new functionality, the <addToQuery> setting in the globalsettings.xml file for Internet Server has been changed from a mandatory element to an optional one.
Fix for getcontent memory leak
In wwwopac.ashx 3.7.13323, a memory leak issue with the getcontent command was solved.
Fix in language attributes of unstructured XML
From wwwopac.ashx 3.7.13317, a bug fix ensures that multilingual linked fields in unstructured XML are now returned with filled language attributes.
Automatically delete relations during update record
In wwwopac.ashx 3.7.13315.5, new functionality was added to automatically delete relations between records when updating a record. Linked field data in the updated record will be deleted only when the linked reference field value gets set to empty.
Fix for unstructured multilingual writing
Also in wwwopac.ashx 3.7.13315.5, a fix was implemented for a bug in the writing of multilingual fields belonging to a field group, in unstructured XML.
Allowing scripting in your XSLT stylesheets
From Axiell WebAPI version 3.7.13308 a new adlibweb.xml setting is available to allow you to use the XSLT document() function and embedded scripting to be used in your XSLT stylesheet to transform the XML returned from wwwopac.ashx. (In MSXML 6.0 this feature is disabled by default.)
<globalConfiguration> … <xsltScriptingAllowed>true</xsltScriptingAllowed> </globalConfiguration>
The XSLT document() function provides a way to retrieve other XML resources from within the XSLT stylesheet beyond the initial data provided by the input stream. Allow scripting only if you require script support in the stylesheet and if you are working in a fully trusted environment: if scripts are allowed in the main stylesheet, they will be allowed in all the included files too.
Changes to multilingual grouped XML
The grouped XML format, with regard to multilingual fields, has changed. Before version 3.7.13301.1, the grouped XML format for multilingual data deviated from the new format in the sense that in the XML the multilingual field node was repeated for each language value, like so:
<adlibXML>
<recordList>
<record priref="6">
<priref>6</priref>
<Title>
<title>
<value lang=’en-GB’>Test title English</value>
</title>
<title>
<value lang=’nl-NL’>Test titel Dutch</value>
</title>
<Title>
</record>
</recordList>
</adlibXML>
In the new format, all language values are repeated within a single field node:
<adlibXML>
<recordList>
<record priref="6">
<priref>6</priref>
<Title>
<title>
<value lang=’en-GB’>Test title English</value>
<value lang=’nl-NL’>Test titel Dutch</value>
</title>
<Title>
</record>
</recordList>
</adlibXML>
Empty "lang" attributes no longer allowed when writing data
When you POST grouped XML data to the wwwopac.ashx while one or more of the fields are multilingual, then be sure to structure your XML accordingly. From wwwopac.ashx version 3.7.13301.1, it is mandatory for multilingual fields to always specify a data language in the "lang" attribute of the field to write to; previously, an empty "lang" attribute was allowed. The WebAPI will check the data dictionary (.inf file) of the relevant database to find out if fields are multilingual or not. Thus, the XML format for a new record containing just a multilingual title field (in field group Title) must be structured similarly to the following (where the "lang" attribute cannot be empty):
<adlibXML>
<recordList>
<record>
<priref>0</priref>
<Title>
<title>
<value lang=’en-GB’>Test title English</value>
<value lang=’nl-NL’>Test titel Dutch</value>
</title>
<Title>
</record>
</recordList>
</adlibXML>
while for a monolingual title field you would structure the XML like:
<adlibXML>
<recordList>
<record>
<priref>0</priref>
<Title>
<title>Test title</title>
<Title>
</record>
</recordList>
</adlibXML>
Write-back fields writing implemented
Linked fields in your database may have write-back fields defined for them, which means that in a catalogue record the user can edit or enter information in merged-in fields belonging to a linked record, to be stored with the linked record when the catalogue record is saved. From wwwopac.ashx version 3.7.13301.1, data you write to such merged-in fields will be written back to the relevant linked record if for the linked field the appropriate write-back fields have been specified. In previous versions this data could not be written to the linked record.
Bug fix for saved search (aka pointer file) handling
When reading or writing saved searches with the wwwopac.ashx, an error could occur. The issue was with an uninitialized hit list member of the pointer file object. The issue has been resolved in wwwopac.ashx version 3.7.13301.1.
Feedback
